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ABSTRACT 

Component-Based  Software  Architecture  is  a 
promising  solution  for  distributed  computing.  To  develop 
high  quality  software,  analysis  of  non-functional  aspects 
of  the  software  properties  (also  called  Quality  of  Service 
or  QoS)  is  very  important.  The  UniFrame  research 
project  proposes  a  Unified  Component  Meta-Model 
Framework  (UniFrame)  that  includes  QoS  contracts.  A 
classification  of  QoS  parameters,  both  static  and 
dynamic,  relevant  to  component-based  distributed 
computing  is  proposed  and  represented  formally  using 
Two-Level  Grammar  (TLG),  an  object-oriented  formal 
specification  language.  TLG  may  be  transformed  into 
both  a  UML  model,  augmented  with  OCL  constraints, 
and  executable  code  in  the  Java  programming  language. 
This  may  be  regarded  as  standardized  code  for 
implementation  of  the  distributed  application  with 
dynamic  measurement  of  the  QoS  aspects  incorporated. 
The  approach  is  consistent  with  OMG’s  Model  Driven 
Architecture  (MDA)  in  that  QoS  properties  may  be 
specified  at  the  Platform  Independent  Model  (PIM)  level 
and  then  carried  down  to  the  Platform  Specific  Model 
(PSM)  level  in  implementation. 
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I.  INTRODUCTION 

Component-Based  Software  Architecture  (CBS A),  a 
viable  and  economical  alternative  to  traditional  software 
design  is  also  a  promising  solution  for  distributed 
computing.  Components,  by  definition,  are  independent 
of  the  language  implementation,  tools  and  the  execution 
environment.  In  practice,  the  systems  to  be  modeled  and 
implemented,  and  the  environment  change  frequently. 
UniFrame'  is  a  unified  framework  (Raje  et  ak,  2001)  that 
allows  a  seamless  integration  of  heterogeneous  and 
distributed  software  components.  Each  component 
created  using  the  UniFrame  approach  has  a  Unified 
Meta-component  Model  (UMM)  specification  (Raje, 
2000).  The  core  parts  of  the  UMM  are:  components, 
service  and  service  guarantees,  and  infrastructure.  A 
description  of  non-functional  properties,  also  called 
Quality  of  Service  (QoS)^  is  an  important  aspect  of  a 
UMM  specification. 

In  this  paper,  CBSA  and  formal  specifications  are 
used  to  specify  non-functional  properties,  and  to  convert 
the  natural  language  requirements  of  the  non-functional 
properties  into  application  programs.  In  this  way,  the 
non-functional  aspects  of  the  software  systems  are 
considered  and  integrated  into  the  system,  just  like  the 
functional  aspects.  Since  the  system  is  modeled  formally, 
it  is  easier  to  monitor  and  maintain.  Since  the  system  will 


*  http://www.cs.iupui.edu/uniFrame 
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The  terms  “Non-Functional  Properties”  and  “Quality  of 
Service  (QoS)”  are  used  interchangeably  in  this  paper. 
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be  developed  using  Model  Driven  Architecture  (MDA)^ 
and  the  Unified  Modeling  Language  (UML)‘‘,  the  Object 
Constraint  Language  (OCL)^  is  integrated  into  UniFrame 
to  specify  the  QoS  requirements  of  the  distributed 
computing  applications.  As  an  extension  of  UML,  the 
OCL  is  powerful  and  efficient  in  specifying  the 
constraints  on  the  components  that  cannot  be  easily 
specified  by  UML  diagrams.  The  OCL  is  a  formal 
language,  and  is  compatible  with  the  CBSA.  Thus,  with 
the  OCL  specification,  the  QoS  requirements  can  be 
specified  in  a  formal  way  and  automatically  weaved  into 
the  generated  code. 

The  rest  of  the  paper  is  organized  as  follows.  The 
next  section  describes  the  motivation  for  our  research 
related  to  the  Quality  of  Service  analysis.  The  formal 
language^  we  use^  is  briefly  introduced  in  section  III. 
Section  IV  describes  the  technical  basis  for  our 
specification  and  representation  of  QoS  approach.  The 
overall  structure  of  the  specification  and  automatic 
conversion  is  described  with  a  simple  example  in  section 
V.  This  example  focuses  on  the  integration  of  the  OCL 
and  Model  Driven  Architecture  in  the  QoS  analysis  and 
associated  automation.  This  paper  ends  with  conclusions 
and  future  work. 


II.  QUALITY  OF  SERVICE 

In  Distributed  Component  Systems  (DCS),  the 
Quality  of  Service  (QoS)  aspects  are  as  important  as  the 
functional  aspects.  The  Quality  of  Service  is  a  concept 
which  originated  in  the  networking  area  and  has  been 
extended  to  software  development.  However,  QoS 
aspects  are  complex,  abstract,  not  quantifiable,  and 
difficult  to  specify  and  model  (Yang  et  ah,  2002).  The 
effect  of  QoS  properties  on  the  system  does  not 
necessarily  remain  the  same  all  the  time  (Rosa  et  ak, 
2002).  It  is  especially  difficult  to  model  and  formulate 
these  properties  during  the  early  stages  of  the  software 
development.  In  addition,  QoS  specifications  are  rarely 
supported  by  computer  languages,  methodologies,  or 
tools  (Pal  et  ak,  2000).  Hence,  it  is  not  easy  to  decide  if 
the  system  meets  the  QoS  requirements  until  the  latter 
half  of  the  software  development  phase.  It  is  even  harder 
to  validate  the  non-functional  properties  of  software,  as 
there  are  no  well  accepted  models  for  the  quantification 
of  QoS  parameters.  Because  of  all  these  reasons,  it  is 
more  difficult  to  specify  the  QoS  parameters  than  to 
specify  the  functional  aspects  of  the  software 
requirements. 

However,  to  develop  high  quality  software,  QoS 
properties  have  to  be  taken  into  consideration.  There 
have  been  several  research  projects  with  this  goal,  e.g. 


^  http://www.omg.org/mda/ 
http://www.omg.org/uml/ 

^  http://www-3  .ibm.com/software/ad/library/standards/ockhtml 


Asteri,  Qedo\  QuO*,  to  name  a  few,  but  not  many 
attempts  have  been  made  to  incorporate  QoS  into 
component-based  software  systems,  (an  exception  being 
Campbell  and  Cheng,  2001). 

Our  goal  is  to  describe  the  QoS  parameters  with  a 
formal  language  to  standardize  the  software  development 
of  systems  in  which  QoS  is  integrated.  Natural  Language 
is  too  informal  and  ambiguous  for  the  purpose  of 
describing  QoS  requirements,  but  on  the  other  hand, 
programming  languages  are  not  appropriate  either 
because  of  too  much  detail,  and  some  inherent 
“problems”  of  high  level  programming  languages,  such 
as  platform  dependence.  Formal  specifications  can 
overcome  both  of  these  problems  and  can  also  be 
elegantly  integrated  into  component-based  software 
development  techniques.  Since  it  is  a  formal  specification 
language  at  a  level  of  abstraction  between  natural  and 
programming  languages,  we  use  Two-Level  Grammar 
(TLG)  (Bryant  and  Lee,  2002)  to  specify  QoS 
parameters,  and  convert  them  into  a  UML  specification 
with  integrated  QCL  constraints  and  conforming  to 
MDA. 

In  order  to  specify  and  analyze  the  QoS  properties, 
they  are  divided  into  three  aspects:  non-flinctional 
attributes,  non-flinctional  actions  and  non-flinctional 
properties  (Yang  et  ak,  2002).  Non-ftinctional  attributes 
are  the  features  to  be  specified,  a  significant 
characteristic  of  which  is  its  decomposability  in  the  sense 
that  a  non-ftinctional  attribute  can  be  decomposed  into 
more  detailed  attributes.  Non-ftinctional  actions  are  the 
input  that  has  effect  on  the  non-ftinctional  attributes. 
Non-flinctional  properties  are  the  constraints  of  the  non¬ 
functional  actions  over  the  non-flinctional  attributes.  A 
simple  example  of  these  aspects  is:  the  response  time  of  a 
distributed  system  is  a  non-flinctional  attribute,  and  the 
clients  connecting  into  the  system  or  disconnecting  from 
the  system  are  non-flinctional  actions.  Non-flinctional 
properties  define  how  the  connecting  or  disconnecting 
operation  may  affect  the  non-flinctional  attributes  and 
what  kind  of  response  time  is  expected  in  this  system. 

Four  steps  are  taken  to  assure  the  QoS  of  a 
Distributed  Computing  System  (DCS):  first,  create  a 
catalog  for  the  QoS  parameters;  then  provide  a  formal 
specification  of  them;  third,  construct  a  mechanism  to 
guarantee  the  specified  values  for  these  parameters,  both 
at  the  individual  and  component  level  and  at  the  entire 
system  level,  both  statically  and  dynamically.  Last, 
testing  is  performed  to  make  sure  the  constructed  system 
meets  the  original  requirement  specification,  especially 
with  respect  to  QoS. 

A  catalog  of  Quality  of  Service  parameters  is 
described  in  (Raje  et  ak,  2002).  It  includes  many 
parameters  such  as,  security,  throughput,  capacity,  etc. 


^  http://www-rocq.inria.fr/slidor/work/aster.html 
^  http://qedo.berlios.de 

^  http://www.dist-systems.bbn.com/tech/QuO 
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The  fomat  of  this  catalog  is  based  on  the  fomat  of  the 
design  patterns  catalog  (Gamma  et  ah,  1995),  for  both 
static  and  dynamic  properties. 

A  number  of  architectures  have  been  proposed  for 
QoS  guarantees  for  distributed  systems,  for  example,  the 
Quality  Objects  (QuO)  framework.  This  work  mainly 
emphasizes  specification,  measurement,  control  and 
adaptation  to  changes  in  Quality  of  Service.  Another 
example,  QoS  Modeling  Language  (QML)  is  a  QoS 
specification  language  proposed  in  (Frolund  and 
Koistinen,  1998). 

In  UniFrame,  we  formally  specify  the  quality  of 
components  and  component  complexes  (results  of 
compositions  of  components).  The  aspects  of  a  meta¬ 
model  are  specified  and  verified  in  the  context  of 
combining  heterogeneous  components.  This  provides  a 
QoS  management  approach  to  the  interactions  between 
clients  and  servers  for  distributed  object  systems  by 
supporting  frameworks  for  multiple  QoS  categories.  The 
following  features  of  the  UniFrame  approach,  for  QoS, 
distinguish  it  from  other  related  efforts: 

1.  Creation  of  a  QoS  Catalog  for  software  components 
containing  detailed  descriptions  about  QoS  attributes 
of  software  components  including  the  metrics, 
evaluation  methodologies  and  the  interrelationships 
with  other  attributes. 

2.  Integration  of  QoS  at  the  individual  component  and 
distributed  system  levels. 

3.  Formal  specifications  based  on  Two-Level 
Grammar. 

4.  The  validation  and  assurance  of  QoS,  based  on  the 
concept  of  event  grammars  (Auguston,  2000). 

5.  An  investigation  of  the  effects  of  component 
composition  on  QoS;  involving  the  estimation  of  the 
QoS  of  an  ensemble  of  software  components  given 
the  QoS  of  individual  components. 

6.  The  automatic  translation  from  natural  language  to 
formal  specification  languages,  and  then  to  UML 
class  diagrams  and  application  programs. 

7.  An  integration  of  OCL  to  specify  the  QoS  properties 
and  to  convert  to  high  level  programming  languages. 

8.  The  conformance  to  the  OMG  MDA  standard  by 
specifying  QoS  in  Platform  Independent  Models  and 
implementing  it  in  Platform  Specific  Models. 


m.  TWO-LEVEL  GRAMMAR 

In  UniFrame,  Two-Level  Grammar  (TLG)  is  used  to 
specify  the  QoS  parameters.  TLG  is  a  formal 
specification  language,  originally  developed  as  a 
specification  language  for  programming  language  syntax 
and  semantics,  and  later  used  as  an  executable 
specification  language  and  as  the  basis  for  conversion 
from  requirements  expressed  in  natural  language  into 
formal  specifications.  It  is  a  formal  notation  based  upon 
natural  language  and  the  functional,  logic  and  object- 
oriented  programming  paradigms.  The  combination  of 


natural  language  and  formalization  is  unique  to  TLG  and 
also  fits  the  Unified  Meta-component  Model  (UMM) 
(Raje,  2000)  for  component  description  used  in 
UniFrame  well.  The  specification  in  TLG  is  easy  to  read 
and  may  be  automatically  generated  from  natural 
language  requirements  specifications  (Lee  and  Bryant, 
2002a). 

TLG  is  suitable  for  representing  QoS  properties 
because  with  its  class  hierarchy  that  corresponds  to  the 
way  we  describe  QoS  properties  (Yang,  et  ah,  2002),  we 
can  take  advantage  of  CBSA  and  component  reuse. 
Especially  since  it  supports  multiple  inheritance,  it  may 
be  used  to  represent  the  decomposability  of  the  QoS 
properties.  The  instance  variables  and  functions  can  be 
used  to  represent  the  QoS  attributes  and  actions.  TLG  has 
a  high  level  of  abstraction  and  its  representation  is 
flexible  -  not  all  the  members  have  to  be  quantifiable, 
and  this  suits  the  feature  of  QoS  properties  since  most  of 
the  effects  of  the  QoS  are  either  existent  or  not  existent, 
instead  of  being  a  quantifiable  concept. 

IV.  OCL,  MDA  AND  QUALITY  OF  SERVICE 

The  specification  of  the  OCL  is  a  part  of  the  UML 
specification,  and  it  is  not  intended  to  replace  existing 
formal  languages,  but  to  supplement  the  need  to  describe 
the  additional  constraints  about  the  objects  that  cannot  be 
easily  represented  in  graphical  diagrams,  like  the 
interactions  between  the  components  and  the  constraints 
between  the  components’  communication.  In  object- 
oriented  modeling,  a  graphical  model,  such  as  a  class 
diagram,  is  not  enough  for  a  precise  unambiguous 
specification.  OCL  is  designed  to  solve  this  problem.  It 
facilitates  the  specification  of  model  properties  in  a 
formal  yet  comprehensive  way.  By  combining  the  power 
of  the  straightforward,  graphical  UML  modeling  and  the 
textual,  accurate  OCL  constraints,  these  kinds  of 
information  can  be  specified  in  this  formal  way. 

OCL  has  the  characteristics  of  an  expression 
language,  a  modeling  language  and  a  formal  language. 
An  OCL  expression  is  guaranteed  to  be  without  side 
effects  since  it  is  an  expression  language,  and  thus  cannot 
change  anything  in  the  model,  although  an  OCL 
expression  can  be  used  to  specify  the  state  changes  of  the 
system.  OCL  is  not  a  programming  language,  but  a 
modeling  language.  So  it  is  impossible  to  write  program 
logic  or  flow-control  in  OCL  (Neema  et  ah,  2002).  All 
implementation  issues  are  likewise  out  of  the  scope  of 
OCL.  OCL  is  also  a  formal  language  where  all  constructs 
have  a  formally  defined  meaning;  in  other  words,  it  is 
unambiguous.  Furthermore,  OCL  is  strongly  typed. 

The  main  idea  behind  OCL  is  “Design  By  Contract” 
(DBC)  (Frankel,  2003).  By  applying  this,  the 
responsibility  of  the  parties  is  made  unambiguous  and 
can  be  formally  described.  An  OCL  constraint  consists  of 
the  precondition,  the  postcondition  and  the  invariant.  The 
contract  is  a  way  of  establishing  who  does  what  by 
stating,  first,  what  must  be  true  for  the  caller  (say,  client. 


3 


for  example)  to  request  a  service  from  the  callee  (server, 
for  example)  (precondition),  and,  what  must  be  true  when 
the  callee  finishes  providing  the  service  (postcondition). 
The  invariant  must  be  true  when  a  routine  is  called  and 
when  it  terminates,  but  not  necessarily  when  it  is 
executing.  By  the  principle  of  “Design  By  Contract”, 
and  specifying  these  three  constraints,  the  services 
provided  by  the  server  are  exposed,  but  not  the  details  of 
the  implementation  of  the  services. 

On  the  other  hand,  the  callee  will  know  when  exactly 
a  service  can  be  provided  (available),  and  the  caller  will 
know  when  exactly  it  can  request  the  service.  In  case  of 
exceptions,  it  is  easy  to  find  out  who  caused  the 
exception;  if  the  precondition  is  false,  the  caller  broke  the 
contract;  if  the  postcondition  is  false,  the  callee  broke  the 
contract;  if  the  invariant  is  false,  the  callee  class  broke 
the  contract. 

Since  OCL  is  a  textual  extension  of  the  graphical 
UML  modeling  language,  an  OCL  specification  is  always 
unambiguous  and  precise,  also,  it  provides  better 
documentation  to  the  visual  models.  It  can  be  used  during 
the  modeling  and  specification.  Since  OCL  is  an 
expression  language,  it  can  be  checked  without  an 
executable  system.  All  these  features  turn  out  to  be  useful 
in  representing  QoS  properties,  which  can  be  represented 
by  the  combination  of  precondition,  postcondition  and 
invariant  in  OCL.  The  QoS  attributes  are  represented  by 
the  member  variables  of  the  class,  and  the  QoS  actions 
are  represented  by  the  methods.  They  are  checked  at  run 
time,  before  and  after  the  calls  so  that  the  change  of  the 
QoS  parameters  of  the  system  is  monitored  in  a  timely 
basis. 

The  precondition  has  to  be  satisfied  before  the 
method  can  be  called,  and  the  postcondition  has  to  be 
satisfied  at  the  time  the  method  returns.  It  is  easy  to  find 
out  which  step  causes  exceptions  if  any.  The  methods  are 
called  in  a  loop-like  fashion,  so,  whenever  a  change  of 
the  QoS  parameter  is  observed  (by  some  method),  the 
corresponding  methods  are  called  and  the  changes  are 
made  accordingly  and  the  necessary  notification  is  done 
at  the  same  time.  The  QoS  specification  is  integrated  in 
the  overall  system  design  in  this  fashion.  In  this  way,  the 
satisfaction  of  the  QoS  requirements  is  guaranteed  and 
the  change  of  the  QoS  properties  is  under  observation 
and  control,  as  well. 

Although  QoS  properties  and  associated  metrics  have 
been  widely  used  in  networking,  there  is  no  standard 
vocabulary  for  discussing  the  QoS  as  it  relates  to  the 
distributed  computing  and  component-based  solutions 
(Burt  et  ak,  2002),  especially  when  the  QoS  properties 
are  applied  on  variant  platforms  and  when  the  different 
aspects  of  the  QoS  interact  with  each  other.  A  standard 
vocabulary  is  the  first  step  toward  progressing  Model 
Driven  Architecture  that  includes  QoS  parameterization 
and/or  QoS  contracts.  This  is  one  of  the  goals  of  the 
UniFrame  project. 

MDA  provides  an  open,  vendor-neutral  environment 
for  the  integration  of  different  distributed  application 


software.  MDA  aims  to  separate  the  business  or 
application  logic  from  the  underlying  platform 
technology.  Its  standards  are  made  up  of  the  Unified 
Modeling  Language  (UML),  Meta-Object  Facility 
(MOF),  XML  Meta-Data  Interchange  (XMI),  and 
Common  Warehouse  Meta-model  (CWM)  (Frankel, 
2003).  Platform-independent  applications  built  using 
MDA  and  the  associated  standards  can  be  realized  on  a 
range  of  platforms. 

MDA  has  standards  that  enable  the  use  of  generative 
techniques  for  the  construction  of  interoperability  bridges 
between  different  platform  technologies.  In  a  distributed 
environment,  it  is  normal  to  see  different  components  of 
the  system  running  on  dispersed  and  different  platforms, 
and  using  various  techniques.  By  applying  the  MDA 
architecture,  the  detailed  difference  is  hidden  from  the 
application  layer.  This  is  especially  useful  for  the 
modeling,  analysis  and  control  of  QoS  of  the  systems. 

The  MDA  design  initiative  assists  during  the 
interaction  between  the  different  platforms  and  different 
middleware.  Middleware  environments  started  out 
providing  the  interoperability  using  the  architectures  that 
are  standard,  proprietary,  or  somewhere  in  the  middle. 
Progressively,  more  and  more  services  and  more 
powerful  middleware  have  been  added  to  the  overall 
architecture,  thus,  it  is  more  difficult  to  ensure  the 
interoperability  of  these  middleware.  To  efficiently  solve 
this  problem,  MDA  is  designed  by  applying  the 
component  and  modeling  technology  and  putting  the 
whole  picture  together. 

There  are  several  core  models  in  MDA:  one 
represents  the  enterprise  computing  with  its  component 
structure  and  transactional  interaction;  another  represents 
the  real-time  computing  (which  is  an  important  part  of 
QoS)  with  its  special  needs  for  resource  control,  and 
some  others  to  represent  specialized  environments.  Each 
of  these  models  will  be  independent  of  any  middleware 
platform. 

MDA  defines  two  models:  Platform  Independent 
Model  (PIM)  and  Platform  Specific  Model  (PSM)  and 
the  conversion  between  the  PIM  and  the  PSM.  A  PIM 
describes  the  business  processes  and  entities  in  terms  of 
components,  and  does  not  specify  the  implementation  of 
the  software  system  as  such.  A  PSM,  however,  describes 
how  to  build  the  components  given  a  specific  technology 
by  applying  mapping  profiles,  that  targets  different 
software  technology  technologies.  It  works  together  with 
the  domain  business  information  model  and  some  other 
details.  Flence,  the  PIM  and  the  PSM  separate  the  design 
model  from  the  implementation  model  by  providing 
multiple  layers,  and  each  of  which  focusing  on  different 
level  of  abstraction  and  platform  and  domain 
information. 

The  first  step  when  constructing  an  MDA-based 
application  will  be  to  create  a  platform  independent 
application  model  expressed  via  UML  in  terms  of  the 
appropriate  core  model.  Adding  new  middleware 
platforms  to  the  interoperability  environment  is 
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straightforward;  after  identifying  the  way  a  new  platform 
represents  and  implements  common  middleware 
concepts  and  functions,  this  information  is  incorporated 
into  the  MDA  as  a  mapping. 

V.  OCL/MDA  INTEGRATION  FOR  QOS 
ANALYSIS 

UML  has  been  popularly  used  in  object-oriented 
design  and  is  useful  for  modeling  systems,  their  behavior 
and  interaction.  However,  UML  currently  does  not 
support  the  modeling  of  QoS  properties  of  objects  or 
components  and  there  is  no  special  attention  to  model 
quality  requirements  or  to  express  in  UML  QoS  aspects 
of  software  architectures  (UML,  2002). 

We  present  a  formal  semantics  for  the  object 
constraint  language  that  is  part  of  the  UML.  In  the 
context  of  information  systems  modeling,  UML  class 
diagrams  can  be  utilized  for  describing  the  overall 
structure,  whereas  additional  integrity  constraints  and 
queries  are  specified  with  OCL  expressions. 

The  Generic  Modeling  Environment  (GME)  (GME, 
2001)  is  a  configurable,  domain-specific,  model- 
integrated  tool  for  creating  and  evolving  domain  specific, 
multi-aspect  model  of  systems  developed  by  the  Institute 
for  Software  Integrated  Systems  (ISIS)  at  Vanderbilt 
University’.  OCL  is  embedded  in  GME  to  specify  the 
constraints  of  the  interactions  between  different 
components  of  the  system  to  be  modeled  (Gray,  2001). 

GME  uses  the  technique  of  Model  Integrated 
Computing  (MIC)  (Nordstrom,  et  al.,  1999).  MIC  is  a 
methodology  for  generating  application  programs 
automatically  from  multi-aspect  models.  GME 
automatically  generates  the  meta  level  specification,  and 
does  not  depend  on  the  specific  domain  the  application  is 
in. 

Since  GME  supports  the  specification  of  OCL 
constraints,  we  can  use  this  tool  to  specify  our  QoS 
specification  in  OCL  and  integrate  with  the  other  aspects 
of  the  software  requirements,  and  generate  the 
apphcation  level  programs,  as  either  UML  models,  or 
object  oriented  programming  language  programs. 

With  the  idea  of  Platform  Independent  Modeling 
(PIM)  in  MDA,  if  we  specify  the  QoS  of  a  system  in  a 
way  that  conforms  to  the  MDA  standard,  this 
specification  will  be  able  to  be  applied  to  any  platform 
without  worrying  about  the  difference  of  details  in  the 
domain  or  platform,  environment  this  specification  is 
apphed. 

We  would  like  to  use  a  simple  ATM  example  to 
demonstrate  the  process  of  converting  the  QoS 
specification  from  natural  language  into  a  modeling 
language  (Lee  and  Bryant,  2002a).  A  brief  description  of 
the  QoS  requirements  of  the  ATM  (Yang  et  al.,  2002)  is 
reprinted  here: 


g 
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ATM's  security  property  is  as  foiiows.  The  iength  of  the 
encryption  byte  shouid  be  bigger  than  3  and  the  aiiowed 
attempts  have  to  be  smaiier  than  the  maximum  aiiowed 
attempts.  If  the  encryption  byte  iength  is  6  and  the  maximum 
aiiowed  attempts  is  iess  than  5  then  the  system  is  80%  secure. 
If  the  account  type  is  a  savings  account  or  the  maximum 
aiiowed  connections  of  the  bank  is  iess  than  50  or  the  deiay 
ievei  is  iess  than  50  then  the  maximum  aiiowed  attempts  is 
iimited  to  4. 

If  the  user  timeout  is  between  10000  and  120000 
miiiiseconds  we  have  a  good  deiay  ievei.  If  the  response  time  is 
ionger  than  30000  miiiiseconds,  the  deiay  ievei  drops  down  to 
40%. 

The  conversion  process  from  a  natural  language 
requirements  document  into  executable  code  is  shown  in 
Eigure  1.  Eirst,  we  start  with  a  natural  language 
description  of  the  QoS  parameter.  We  are  mainly 
concerned  with  “security”  issues  in  this  example.  Since 
TLG  is  a  natural  language-like  formal  specification 
language,  it  is  easy  to  read  and  it  is  easier  to  convert  the 
natural  language  specification  to  TLG  than  to  convert  to 
other  formal  specification  languages.  To  convert  from 
natural  language  description  to  TLG  specification,  the 
QoS  property  description  is  first  represented  in  XML  to 
specify  which  role  each  sentence  plays. 

A  sample  XML  representation  of  the  ATM  example 
is  shown  as  follows. 

<document> 

<c  title=”ATM”> 

<c  title=”Security”> 

<p  meta=”satisfaction  check”> 

<s>The  length  of  the  encryption  byte  should 
be  bigger  than  3  and  the  allowed 
attempts  has  to  be  smaller  than  the 
maximum  allowed  attempts 
</s> 

</p> 


<p  meta=”level  update”> 

<s>lf  the  encryption  byte  length  is  6  and  the 
allowed  attempts  is  less  than  5  then  the 
system  is  80%  secure 
</s> 

</p> 

<p  meta=”attribute  update”> 

<s>lf  the  account  type  is  a  savings  account 
or  the  maximum  allowed  connections  of 
the  bank  is  less  than  50  or  the  delay 
level  is  less  than  50  then  the  maximum 
allowed  attempts  is  limited  to  4 
</s> 

</p> 

</c> 
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<c  title=”Delay”> 

<p  meta=”satisfaction  check”> 

<s>lf  the  timeout  is  between  10000  and 
120000  miiiiseconds  we  have  a  good 
deiay  ievei 
</s> 

</p> 

<p  meta=’1evei  update”> 

<s>lf  the  response  time  is  ionger  than 
30000  miiiiseconds  the  deiay  ievei  drops 
down  to  40% 

</s> 

</p> 

</c> 

</c> 

</document> 

Given  this  XML  representation  of  QoS,  each 
sentence  of  the  specification  is  tokenized  and  then  by 
using  computational  linguistics  parsing  techniques  the 
system  constructs  its  parsing  tree  (Lee  and  Bryant, 
2002b). 

Based  on  the  above  parsing  tree  and  the  meta 
information  from  the  XML  tags,  a  Knowledge  Base  is 
constructed.  The  Knowledge  Base  is  an  explicit  and 
declarative  representation  that  is  used  to  represent, 
maintain,  and  manipulate  knowledge  about  QoS  of  the 
system. 

This  Knowledge  Base  is  converted  into  TLG  by 
identifying  the  classes,  data  types,  and  operations  as 
shown  below; 

class  Property. 

Level ::  Integer. 

end  class. 

class  Bank_Capaclty  extends  Property. 
Maxlmum_Connectlons ::  Integer. 

end  class. 


class  ATM_Securlty  extends  Property. 

Maxlmum_Allowed_Attempts ::  Integer. 
Encryptlon_Byte_Length ::  Integer. 

Allowed_Attempts ::  Integer. 

Account_Type ::  String. 

check  satisfaction: 

Encryptlon_Byte_Length  >  3, 

Allowed_Attempts  <  Maxlmum_Allowed_Attempts. 

update  level: 

Encryptlon_Byte_Length  =  6; 

Allowed_Attempts  <  5, 

Level  :=  80. 


update  attributes: 

Account_Type  =  “savings”, 
Maxlmum_Allowed_Attempts  :=  4; 
Bank_Capaclty.Maxlmum_Connectlons  <  50, 
Maxlmum_Allowed_Attempts  :=  4; 

ATM_Delay.Level  <  50, 
Maxlmum_Allowed_Attempts  :=  4. 

end  class. 

class  ATM_Delay  extends  Property. 

Response_Tlme ::  Integer. 

User_Tlmeout ::  Integer. 

check  satisfaction: 

User_Tlmeout  >  10000,  User_Tlmeout  <  120000. 
update  level: 

Response_Tlme  >  30000,  Level  :=  40. 
end  class. 

Because  OCL  is  also  a  formal  language,  it  can  be 
used  to  represent  the  constraints  of  the  QoS  properties. 
Our  next  step  is  to  convert  the  TLG  specification  of  QoS 
into  OCL  specification.  A  partial  OCL  code  is  listed 
here: 

ATM_Securlty 
level:  Integer 

encryptlon_byteJength:  Integer 
allowed_attempts:  Integer 
max_allowed_attempts:  Integer 
acccuntjype:  String 

checkSatlsfactlcn  () 
updateLevel  () 
updateAttrlbutes  () 

ATM_Securlty::checkSatlsfactlon  () 

Pre:  encryptlon_byteJength  >  3  and 

allowed_attempts  <  max_allowed_attempts 

Post:encryptlon_byteJength>= 

encryptlon_byteJength@pre  and 
allowed_attempts  <=  allowed_attempts@pre 

ATM_Securlty::updateLevel  () 

Pre:  encryptlon_byteJength  ==  6  and 
allowed_attempts  <  5 
Post:  level  =  80 

ATM_Securlty::updateAttrlbutes  () 

Pre:  accountjype  ==  “savings” 

Post:  max_allowed_attempts  =  4 
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As  indicated  earlier,  OCL  is  an  expression  language, 
so  OCL  constraints  cannot  directly  affect  any  models 
created  using  the  target  modeling  language.  The 
constraint  expressions  are  merely  formal  comments  on 
the  semantics  of  the  modeling  language.  Models  created 
using  the  target  modeling  language  can  be  verified  using 
the  OCL  expressions,  but  the  expressions  cannot  cause 
any  changes  in  the  models.  This  exactly  suits  our  need  to 
specify  the  QoS  properties  since  it  is  commonly  known 
that  some  of  the  QoS  properties  may  change  dynamically 
during  the  execution  of  the  program,  or  because  of  some 
outside  influence.  OCL  is  perfect  for  representing  these 
properties  at  the  same  time,  as  it  does  not  change  the 
properties. 

OCL  is  a  formal  language,  since  every  component  of 
it  has  its  exact  meaning  and  it  is  unambiguous.  Another 
advantage  of  OCL  is  that  it  is  a  widely  accepted  standard 
language,  and  has  a  friendly  interface  with  other  formal 
languages  and  modeling  languages. 

The  syntax  and  semantics  of  TLG  and  OCL  are 
similar  to  some  extent  which  simplifies  the  conversion. 
The  conversion  from  the  TLG  specification  to  the  OCL 
constraints  can  be  achieved  by  the  mapping  of  the 
member  variables  of  the  TLG  and  of  the  OCL.  Both  TLG 
and  OCL  are  strongly  typed.  The  method  conversion 
between  these  two  specifications  is  achieved  by  the 
context  analysis. 

Using  GME,  we  can  parse  the  OCL  constraints  and 
generate  the  UML  model  or  object  oriented  programming 
language  program  code,  e.g.,  Java.  Especially,  one  of  the 
nice  features  of  GME  is  the  conversion  between  meta 
level  and  domain  level  as  shown  in  Eigure  1 . 

After  we  convert  from  TLG  specification  of  QoS  into 
OCL,  by  the  OCL  parser,  the  application  domain 
programs  or  models  can  be  generated,  regardless  of  the 
specific  domain  of  this  application.  So  the  QoS 
properties  are  extracted  from  the  domains  and  can  all  be 
specified  in  a  uniform  way. 

The  UML  class  diagram  of  the  QoS  specification  of 
the  ATM  example  is  shown  in  Eigure  2. 

In  this  approach,  the  domain  dependence  can  be 
masked  by  the  GME  tool,  the  platform  dependent 
problem  can  be  solved  by  integrating  the  MDA 
architecture.  Since  this  approach  will  conform  to  the 
MDA  standard,  the  specification  of  the  QoS  in  this  way 
is  platform  independent  in  the  sense  that  the  specification 
of  the  QoS  parameters  does  not  have  any  platform 
dependent  information  or  constraints,  thus  is  applicable 
in  any  environment.  In  the  distributed  environment,  when 
only  the  interfaces  of  the  components  are  exposed,  this 
QoS  specification  can  be  integrated  into  the  overall 
system  design. 

As  far  as  platform  independence  is  concerned,  we  are 
taking  the  approach  of  MDA  converting  from  PIM  to 
PSM. 

The  catalog  of  QoS  parameters  we  create  applies  to 
all  platforms,  regardless  of  the  programming  language 


used  to  achieve  it.  In  the  design  phase,  the  software 
system  is  designed  in  a  platform  independent  manner  in 
which  the  QoS  properties  are  integrated  as  components. 
It  is  implemented  by  applying  the  state-of-the-art 
software  technology,  resulting  in  a  platform  dependent 
system  instance.  In  this  way,  the  detail  does  not  need  to 
be  considered,  and  there  is  no  reason  to  let  too  much 
detail  affect  the  design  of  the  software.  As  long  as  we  can 
specify  the  QoS  properties  in  design  level,  they  are 
enforced  at  the  implementation  level,  and  they  apply  to 
varieties  platforms,  which  is  very  common  in  Distributed 
Computing. 

VI.  CONCLUSION  AND  FUTURE  WORK 

Quality  of  Service  properties  of  the  software 
requirements  specification  are  an  important  part  of 
software  design  consideration.  In  our  research,  the  QoS 
requirements  are  described  in  natural  language  and  later 
converted  to  UML  or  high  level  programming  languages. 
By  this  way,  people  working  in  different  domains  can 
specify  their  QoS  requirements  that  will  later  be 
converted  into  the  formal  modeling  language.  With  the 
integration  of  OCL  and  MDA,  more  detailed 
requirements  can  be  accurately  expressed  in  the 
modeling  stage  of  the  software  design,  and  the  details  of 
different  platforms  and  operating  systems  are  hidden 
from  the  software  designers  and  developers,  which  is 
especially  beneficial  in  the  distributed  applications. 

Our  future  work  is  to  automate  the  conversion  of 
OCL,  and  implement  the  representation  within  MDA, 
and  hopefully  automate  the  standard  documentation 
generation.  At  the  same  time,  we  plan  to  improve  the 
compatibility  of  the  conversion.  The  improvement  of  the 
usability  of  the  system  is  another  goal. 
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Figure  2:  UML  for  QoS  of  ATM 
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